Network nodes (e.g., stations, access points, bridges, routers) typically receive data via an ingress interface and transmit data via an egress interface. For example, data intended for a network node enters the network node through an ingress interface, and data having originated in the network node is transmitted from the network node through an egress interface. However, in some cases, data not intended for a particular network node may be received by the network node. In such cases, the data only transits the node and is subsequently retransmitted by the network node. A conventional network node typically buffers data that transits the network node.
The ingress interface(s) of a network node may operate at a different speed than the egress interface(s) of a network node. For example, when the ingress interface is a bus and the egress interface is a noisy wireless interface, the ingress interface may be significantly faster than the egress interface. Thus, data may be received faster than the data can be retransmitted. Buffering received data before retransmitting the data facilitates resolving some issues associated with mismatches between ingress rates and egress rates. For example, “bursty” traffic may be received via a fast ingress interface at a network node. The burst may overwhelm the egress interface, and thus some data to be retransmitted may be buffered. While buffering data may address some issues, buffering data may introduce additional issues including, for example, unacceptable latency and congestion spillover. Latency corresponds to the amount of time between when data is received and when that data is retransmitted.
Prior Art FIG. 1 illustrates one congestion spillover issue produced by buffering data. A network node 100 may handle traffic for two different stations, (e.g., STA1 110 and STA2 120). Data for both STA1 110 and STA2 120 may be received in network node 100 via channel 130. The data may be buffered in buffer 140. Buffer 140 may store traffic (e.g., data, packets) for both STA1 110 and STA2 120. Buffer 140 may employ a first-in first-out (FIFO) approach. Example packets in buffer 140 are labeled with their destinations (e.g., STA1, STA2).
If the path to STA1 110 is congested or slow, and if a burst of traffic for STA1 110 arrives via the relatively faster channel 130, then the buffer 140 may fill with packets for STA1 110. Now consider a packet arriving for STA2 120. The path to STA2 120 may be uncongested and fast. However, a packet arriving for STA2 120 may be placed in the buffer 140 behind all the packets waiting for retransmission over the congested or slow path to STA1 110. A delay between the network node 100 and STA1 110 has spilled over and created a delay between network node 100 and STA2 120 even though there is no actual delay between network node 100 and STA2 120. This delay may produce unacceptable latency for the packet for STA2 120.
At first glance, it may seem appropriate to simply configure network node 100 with separate buffers for separate destinations. However, this intuitive approach may actually be very complicated to implement and may require significant additional expensive resources for a network node.
While Prior Art FIG. 1 introduces congestion spillover leading to unacceptable latency using traffic for two stations, latency issues due to buffering data may be present with a larger number of stations, or even with a single station. Additionally, while a network node 100 acting as an access point (AP) for stations STA1 110 and STA2 120 is illustrated, other non-AP network nodes (e.g., routers, bridges, repeaters) may experience similar latency issues.
A single station could experience unacceptable latency when, for example, the ingress interface is much faster than the egress interface to that single station. In some circumstances, dropping data or dropping a packet may be preferable to holding on to a packet for an unacceptably long period of time before retransmitting the packet.